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ABSTRACT 

Recently  there  has  been  much  interest  in  performing  search  queries 
over  encrypted  data  to  enable  functionality  while  protecting  sensi¬ 
tive  data.  One  particularly  efficient  mechanism  for  executing  such 
queries  is  order-preserving  encryption/encoding  (OPE)  which  re¬ 
sults  in  ciphertexts  that  preserve  the  relative  order  of  the  underlying 
plaintexts  thus  allowing  range  and  comparison  queries  to  be  per¬ 
formed  directly  on  ciphertexts.  Recently,  Popa  et  al.  (S&P  2013) 
gave  the  first  construction  of  an  ideally-secure  OPE  scheme  and 
Kerschbaum  (CCS  2015)  showed  how  to  achieve  the  even  stronger 
notion  of  frequency-hiding  OPE.  However,  as  Naveed  et  al.  (CCS 
2015)  have  recently  demonstrated,  these  constructions  remain  vul¬ 
nerable  to  several  attacks.  Additionally,  all  previous  ideal  OPE 
schemes  (with  or  without  frequency-hiding)  either  require  a  large 
round  complexity  of  0(log  n)  rounds  for  each  insertion ,  or  a  large 
persistent  client  storage  of  size  O(n),  where  n  is  the  number  of 
items  in  the  database.  It  is  thus  desirable  to  achieve  a  range  query 
scheme  addressing  both  issues  gracefully. 

In  this  paper,  we  propose  an  alternative  approach  to  range  queries 
over  encrypted  data  that  is  optimized  to  support  insert-heavy  work¬ 
loads  as  are  common  in  “big  data”  applications  while  still  maintain¬ 
ing  search  functionality  and  achieving  stronger  security.  Specifi¬ 
cally,  we  propose  a  new  primitive  called  partial  order  preserving 
encoding  (POPE)  that  achieves  ideal  OPE  security  with  frequency 
hiding  and  also  leaves  a  sizable  fraction  of  the  data  pairwise  in¬ 
comparable.  Using  only  0(1)  persistent  and  0(ne)  non-persistent 
client  storage  for  0  <  e  <  1,  our  POPE  scheme  provides  extremely 
fast  batch  insertion  consisting  of  a  single  round,  and  efficient  search 
with  0(1)  amortized  cost  for  up  to  0(n1-e)  search  queries.  This 
improved  security  and  performance  makes  our  scheme  better  suited 
for  today’s  insert-heavy  databases. 

1.  INTRODUCTION 

Range  queries  over  big  data.  A  common  workflow  in  “Big  Data” 
applications  is  to  collect  and  store  a  large  volume  of  information, 
then  later  perform  some  analysis  (i.e.,  queries)  over  the  stored  data. 
In  many  popular  NoSQL  key-value  stores  such  as  Google  BigTable 
[14]  and  its  descendants,  e.g.  [17,  41.  42,  43],  the  most  important 
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query  operation  is  a  range  query ,  which  selects  rows  in  a  contigu¬ 
ous  block  sorted  according  to  any  label  such  as  an  index,  times¬ 
tamp,  or  row  id. 

In  order  to  support  high  availability,  low  cost,  and  massive  seal- 
ability.  these  databases  are  increasingly  stored  on  remote  and  po¬ 
tentially  untrusted  servers,  driving  the  need  to  secure  the  stored 
data.  While  traditional  encryption  protects  the  confidentiality  of 
stored  data,  it  also  destroys  ordering  information  that  is  necessary 
for  efficient  server-side  processing,  notably  for  range  queries.  An 
important  and  practical  goal  is  therefore  to  provide  data  security  for 
the  client  while  allowing  efficient  query  handling  by  the  database 
server. 

In  many  big  data  scenarios,  a  moderate  number  of  range  queries 
over  a  huge  amount  of  data  are  performed.  For  example,  a  typi¬ 
cal  application  might  be  the  collection  of  data  from  low-powered 
sensor  networks  as  in  [45],  where  insertions  are  numerous  and  hap¬ 
pen  in  real-time,  whereas  queries  are  processed  later  and  on  more 
capable  hardware.  In  this  work,  we  target  this  type  of  scenario. 

Range  queries  with  order-preserving  encoding  (OPE).  A  simple 
and  efficient  solution  for  performing  range  queries  over  encrypted 
data  was  recently  proposed  by  Popa  et  al.  [35]  who  showed  how  to 
build  an  order-preserving  encoding  (OPE)  scheme  1 ,  which  guaran¬ 
tees  that  enc(*)  <  enc(y)  iff  x  <  y,  allowing  range  queries  to  be 
performed  directly  over  encoded  values.  Additionally,  this  scheme 
achieves  the  ideal  security  goal  for  OPE  of  IND-OCPA  (indistin- 
guishability  under  ordered  chosen-plaintext  attack)  [7]  in  which  ci¬ 
phertexts  reveal  no  additional  information  beyond  the  order  of  the 
plaintexts.  This  scheme  differs  from  traditional  encryption  in  two 
ways.  First,  the  encoding  procedure  is  interactive  requiring  multi¬ 
ple  rounds  of  communication  between  the  data  owner  (client)  and 
the  database  (server).  Second,  the  ciphertexts  produced  are  mutable 
so  previously  encoded  ciphertexts  may  have  to  be  updated  when  a 
new  value  is  encoded.  This  approach  requires  O(logn)  rounds  of 
communication  and  0(1)  client  storage,  where  n  is  the  number  of 
items  in  the  database. 

A  different  trade-off  between  client  storage  and  communication 
is  given  by  Kerschbaum  and  Schropfer  [30]  achieving  just  0(1) 
communication  to  encode  elements  (from  a  uniform  random  distri¬ 
bution),  but  requiring  O(n)  persistent  client  storage  to  maintain  a 
directory  providing  the  mapping  between  each  OPE  ciphertext  to 
the  corresponding  plaintext  —  proportional  to  the  storage  require¬ 
ments  on  the  remote  database  itself. 

When  used  for  range  searches  over  encrypted  data,  these  two 
schemes  either  require  significant  communication,  or  significant 
client  storage.  Moreover,  in  the  second  of  these  schemes  the  direc¬ 
tory  in  the  persistent  client  storage  depends  on  the  full  dataset.  Thus 

1  We  abuse  notation  and  use  OPE  to  refer  to  both  order-preserving 
encryption  and  order-preserving  encoding. 


Comm.  Rounds 

Amortized 

Communication 

Client  Storage 

Incomparable 

Elements 

Insert 

Query 

Working  set 

Persistent 

Here 

i 

0(1) 

0(1) 

0(ne) 

0(1) 

Popa  et  al.  [35] 

O(log  n) 

O(logn) 

O(logn) 

0(1) 

0(1) 

0 

Kerschbaum  &  Schropfer  [30] 

1 

1 

0(1) 

O(n) 

O(n) 

0 

Figure  1:  Comparison  of  OPE-based  range  search  schemes,  n  is  the  total  number  of  inserts,  and  rn  is  the  total  number  of  search  queries.  The  communication 
complexity  is  given  in  number  of  encrypted  elements.  For  our  scheme  we  require  at  most  0(n1— e)  total  number  of  queries.  In  [35]  and  ours,  the  0(1) 
persistent  storage  is  used  for  storing  the  encryption  key.  The  incomparable  elements  refers  to  the  number  of  element  pairs  (out  of  ©(n2)  total)  that  cannot  be 
compared  even  after  m  queries  are  performed. 


it  is  not  easily  amenable  to  a  setting  with  multiple  inserting  clients, 
a  common  deployment  scenario  in  big  data  applications  (e.g.,  mul¬ 
tiple  weak  sensors  encrypting  and  inserting  data  for  analysis  in  the 
cloud),  as  the  persistent  storage  has  to  be  synchronized  across  all 
the  clients. 

Hence,  we  ask  the  following  question: 

In  the  scenario  of  a  large  number  of  insertions  and  a  moder¬ 
ate  number  of  range  queries,  can  we  design  a  secure  range- 
query  scheme  with  both  small,  non-persistent  client-side  stor¬ 
age  and  much  lower  communication  cost? 

Toward  stronger  security:  frequency-hiding  and  more.  As 

recently  pointed  out  by  Naveed  et  al.  [33],  security  provided  by 
OPE  may  be  insufficient  for  many  applications.  Specifically,  they 
showed  attacks  that  use  frequency  analysis  and  sorting  of  cipher- 
texts  to  decrypt  OPE  encrypted  values  using  some  auxiliary  infor¬ 
mation.  To  counter  the  first  of  these  attacks,  Kerschbaum  [29]  pro¬ 
posed  a  stronger  notion  of  security  (IND-FAOCPA)  that  also  hides 
[he  frequency  of  OPE-encoded  elements  (i.e.  hides  equality).  How¬ 
ever,  even  this  does  not  address  all  known  attacks  on  OPE.  Hence, 
this  paper  asks  the  following  question: 

Can  we  design  an  efficient  range  query  scheme  with  security 
better  than  frequency-hiding? 

1.1  Our  Work 

Our  contribution.  In  this  paper  we  give  a  positive  answer  to 
both  of  the  above  questions,  proposing  an  alternative  range  query 
scheme  that  we  call  partial  order  preserving  encoding  or  POPE. 
Specifically,  our  POPE  construction  satisfies  the  following  proper¬ 
ties  when  storing  n  items  using  0(1)  persistent  and  0(ne)  working 
storage  on  the  client  and  performing  at  most  0(n1_e)  range  queries 
for  any  constant  0  <  e  <  1: 

•  Trivial  insert  operations  consisting  of  1  message  from  the 
client  to  the  server  and  no  computation  for  the  server.  Fur¬ 
thermore,  a  large  number  of  data  insertions  can  be  performed 
only  with  a  single  round  in  a  batch. 

•  0(l)-round  (amortized)  communication  per  range  query. 

•  No  persistent  client  storage  between  operations  except  the 
encryption  key. 

•  Greater  security  than  IND-FAOCPA.  Our  scheme  leaks  noth¬ 
ing  beyond  the  order  of  (some  of  the)  inserted  elements  while 
also  hiding  equality.  Moreover,  a  fraction  of  plaintext  pairs 
remain  incomparable  even  after  the  queries. 

See  Figure  1  for  how  this  compares  to  existing  schemes. 

We  have  implemented  our  construction  and  tested  it  on  a  variety 
of  workloads,  comparing  to  other  schemes  and  also  measuring  its 


network  performance.  We  find  that  our  scheme  is  especially  suit¬ 
able  for  typical  big  data  applications  where  there  are  many  more 
inserts  than  queries.  As  an  example  data  point,  with  about  one  mil¬ 
lion  insertions  and  one  thousand  range  queries,  our  POPE  scheme 
is  20X  faster  than  the  scheme  by  Popa  et  al. 

We  also  experimentally  validate  our  claim  of  improved  security 
by  observing  how  many  data  items  remain  unsorted  (i.e.,  the  server 
cannot  learn  their  relative  order)  after  some  number  of  queries  are 
performed  over  real-world  data.  Specifically,  we  ran  an  experiment 
where  we  inserted  over  2  million  public  employee  salary  figures 
from  [1]  and  then  performed  1000  random  range  queries.  Figure  2 
shows  the  server’s  view  of  the  salary  data  after  various  numbers  of 
queries.  The  black  lines  indicate  elements  whose  position  in  the 
global  order  the  server  knows  (the  shading  of  the  lines  indicates 
the  fraction  of  comparable  points  in  each  value  range  with  lighter 
shading  indicating  a  lower  fraction),  while  the  contiguous  white  re¬ 
gions  represent  data  points  whose  relative  order  is  unknown.  Note 
that  for  a  typical  OPE  scheme,  this  image  would  be  fully  black  (all 
order  revealed). 

See  Section  5  for  more  details  on  our  implementation  and  further 
experimental  data. 

POPE  tree:  no  sorting  when  inserting  data.  Our  main  tech¬ 
nique  to  make  this  possible  is  lazy  indexing.  Specifically,  unlike 
OPE,  we  do  not  sort  the  encoded  values  on  insert,  instead  only 
partially  sorting  values  when  necessary  during  query  execution.  If 
we  regard  the  actual  location  in  the  search  tree  data  structure  as  an 
implicit  encoding  of  an  encrypted  value,  our  scheme  gives  a  par¬ 
tially  ordered  encoding,  and  hence  the  name  of  our  construction, 
POPE  (partial  order  preserving  encoding). 

In  particular,  our  scheme  works  by  building  a  novel  tree  data 
structure  (inspired  by  buffer  trees  [5]).  which  we  call  a  POPE  tree, 
where  every  node  contains  an  unsorted  buffer  and  a  sorted  list  of  el¬ 
ements.  The  invariant  that  we  maintain  is  that  the  sorted  elements 
of  a  node  impose  a  partial  order  on  both  sorted  and  unsorted  ele¬ 
ments  of  its  child  nodes.  That  is,  all  sorted  and  unsorted  values  at 
child  i  will  lie  between  values  i  —  1  and  i  in  the  parent’s  sorted 
list.  We  stress  that  there  is  no  required  relation  between  unsorted 
elements  of  a  node  and  the  elements  of  its  child  nodes.  In  partic¬ 
ular,  unsorted  elements  of  the  root  node  do  not  need  to  satisfy  any 
condition.  That  said,  one  can  simply  insert  a  value  by  putting  it  in 
the  unsorted  buffer  of  the  root  node. 

Having  the  server  incrementally  refine  this  POPE  tree  on  range 
queries  allows  us  to  achieve  both  better  efficiency  and  stronger  se¬ 
curity.  In  particular, 

•  Insertion  is  extremely  simple  by  putting  the  encrypted  label 
in  the  unsorted  buffer  of  the  root  of  the  POPE  tree.  More¬ 
over,  a  large  number  of  items  can  be  inserted  in  a  batch,  and 
the  entire  task  takes  only  a  single  round.  We  note  that  the 
interactive  OPE  scheme  in  [35]  cannot  support  a  batch  in¬ 
sertion,  since  each  insertion  is  involved  with  traversing  and 
changing  the  encoding  tree  structure,  and  it’s  quite  difficult 
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Figure  2:  Server’s  view  of  salary  data  whose  order  is  incrementally  revealed  after  inserting  more  than  2  million  salary  entries  and  then  performing  1000 
random  range  queries.  The  black  lines  indicate  entries  whose  order  is  known  by  the  server,  while  the  white  regions  indicate  entries  that  remain  pairwise 
incomparable  after  some  number  of  queries. 


to  parallelize  this  procedure  maintaining  the  consistency  of 
the  tree  structure. 

•  The  cost  of  sorting  encrypted  elements  can  be  amortized  over 
the  queries  performed.  In  particular,  on  each  query  we  only 
need  to  sort  the  part  of  the  data  that  is  accessed  during  the 
search,  leaving  much  of  the  data  untouched.  This  allows  us 
to  support  range  queries  with  much  better  efficiency  and  si¬ 
multaneously  achieve  stronger  security  by  having  some  frac¬ 
tion  of  pairs  of  elements  remain  incomparable. 

•  Since  encodings  are  sorted  during  searches,  the  cost  of  per¬ 
forming  a  batch  of  search  queries  is  often  much  cheaper  than 
performing  these  queries  individually,  as  later  queries  do  not 
need  to  sort  any  elements  already  sorted  in  earlier  queries. 

We  now  describe  the  key  properties  of  our  data  structure  in  more 
detail.  Intuitively,  thanks  to  the  required  condition  between  sorted 
elements  of  a  node  and  the  elements  of  its  child  nodes,  the  sorted 
values  at  each  node  can  serve  as  an  array  of  simultaneous  pivot 
elements  for  the  elements  in  the  child  nodes,  in  the  sense  of  Quick¬ 
sort  [28].  To  maintain  this  property  we  make  use  of  client  working- 
set  storage  to  partition  a  set  of  unsorted  elements  according  to  the 
values  at  the  parent.  Specifically,  we  require  the  client  to  be  able 
to  read  in  a  list  of  0(ne)  encrypted  values  and  then  to  partition 
a  stream  of  other  encrypted  values  according  to  these  split  points. 
Using  this  amount  of  client  working-set  storage  we  can  ensure  that 
the  depth  of  the  buffer  tree  remains  0(1),  allowing  for  low  amor¬ 
tized  latency  per  client  query.  Note  that  any  elements  stored  in  the 
same  unsorted  buffer  at  the  end  of  the  procedure  remain  incompa¬ 
rable. 

2.  PRELIMINARIES 

2.1  Security  with  No  Search  Queries 

The  security  definitions  of  OPE  variants  consider  how  much  in¬ 
formation  is  revealed  by  the  ciphertexts  that  are  created  when  data 
is  inserted.  This  measure  is  important  since  OPE  ciphertexts  must 
inherently  reveal  ordering  information.  The  ideal  security  achiev¬ 
able  even  without  any  search  queries  is  revealing  ordering  infor¬ 
mation  of  the  underlying  plaintexts  but  nothing  more.  Our  POPE 
scheme,  however,  gives  much  stronger  guarantee  of  revealing  no 
information  about  the  underlying  plaintexts  during  insertion.  In¬ 
stead,  ordering  information  is  gradually  leaked  as  more  and  more 
search  queries  are  performed.  In  this  section,  we  briefly  discuss 


the  security  guarantees  that  OPE  variants  and  our  scheme  provide, 
before  any  search  queries  are  performed. 

Security  of  OPE.  The  security  notion  for  OPE  schemes  is  IND- 
OCPA  (indistinguishability  under  ordered  chosen-plaintext  attack) 
[7,  35]:  Ciphertexts  reveal  no  additional  information  beyond  the 
order  of  the  plaintexts.  However,  Naveed  et  al.  [33]  demonstrated 
this  level  of  security  is  sometimes  insufficient,  by  showing  how 
the  revealed  order  can  be  used  to  statistically  recover  a  significant 
amount  of  plaintext  data  in  an  OPE-protected  medical  database. 
Security  of  frequency-hiding  OPE.  To  address  the  above  issue, 
Kerschbaum  [29]  proposed  a  stronger  security  notion,  called  indis¬ 
tinguishability  under  frequency-analyzing  ordered  chosen  plaintext 
attack  (IND-FAOCPA).  Informally,  the  definition  requires  that  ci¬ 
phertexts  reveal  no  additional  information  beyond  a  randomized 
order  of  the  plaintexts.  A  randomized  order  Y  (some  permutation 
of  [n]  for  n-element  sequences)  of  some  sequence  X  of  possibly 
non-distinct  elements  is  an  ordering  you  can  obtain  front  the  se¬ 
quence  by  breaking  ties  randomly.  For  example,  the  randomized 
order  of  X\  =  (1,4,  2,9)  or  X2  =  (2,8,5,20)  could  only  be 
Y\  =  (1,  3,  2, 4)  (meaning  “first  in  sorted  order  was  inserted  first, 
third  in  sorted  order  was  inserted  next,”  and  so  on)  because  X\ ,  A'2 
began  totally  ordered.  However,  the  sequence  X3  =  (1,2,  2, 3) 
has  two  possible  randomized  orders,  namely  Y2  =  (1,  2,  3, 4)  and 

y3  =  (l,3,2,4). 

Note  that  for  any  randomized  order,  e.g.  Y\  =  (1,3,  2, 4),  there 
are  many  sequences  that  could  map  onto  it  (depending  only  on  the 
domain  of  the  sequence  and  the  constraints  imposed  by  known  par¬ 
tial  order  information  on  the  sequence).  This  property  of  a  ran¬ 
domized  order  is  useful  for  hiding  frequency.  The  motivating  ex¬ 
ample  for  frequency-hiding  security  is  a  database  that  stores  a  large 
number  n  of  encodings  for  which  the  underlying  label  space  C  = 
{£1, ...,  It }  is  small,  i.e.,  T  <C  n.  For  example,  [29]  considered  a 
setting  where  each  label  is  either  £1  =  “female”  ( F )  or  I2  =  “male” 
(M),  with  the  sequence  (F.  F,  M,  M)  ideally  encoded  as,  say, 
(2, 1,3,4).  Examining  only  (2, 1,3,4)  does  not  reveal  if  the  under¬ 
lying  sequence  was  originally  (F,  F,  F,  F),  ( F ,  F,  F,  M ),  (F,  F, 
M,  M),  (M,  F,  M,  M),  or  (M,  M,  M,  M). 

To  turn  an  OPE  scheme  into  a  frequency-hiding  OPE  scheme, 
consider  adding  a  small,  random  fractional  component  to  the  OPE- 
ordered  field  during  encoding,  e.g.  X\  =  (1, 1,  2,  2)  becomes  e.g. 
X[  =  (1.12, 1.36,2.41,2.30),  which  randomly  maps  X\  to  the 
ordering  Y  =  (1,  2, 4,  3),  and  then  X[  is  encoded  under  the  OPE 
scheme.  In  [29],  this  type  of  scheme  is  shown  IND-FAOCPA  secure 
in  the  programmable  random  oracle  model. 


We  use  this  approach  to  add  frequency  hiding  in  POPE.  How¬ 
ever,  even  this  stronger  definition  fails  to  protect  against  all  known 
attacks  as  it  still  reveals  the  order  between  all  distinct  plaintexts  in 
the  database,  allowing  for  sorting-based  attacks. 

Security  of  POPE.  POPE,  on  the  other  hand,  fully  hides  all  in¬ 
serted  plaintexts  until  search  queries  are  performed.  Looking  ahead, 
our  POPE  scheme  encrypts  an  item  using  semantically  secure  en¬ 
cryption.  This  implies  in  the  POPE  construction,  ciphertexts  reveal 
no  information  about  the  underlying  plaintexts.  Of  course,  it  is  not 
sufficient  to  just  discuss  security  on  insert  without  considering  what 
happens  on  queries.  Thus,  we  give  a  security  definition  below  cap¬ 
turing  what  happens  both  on  insertion  and  during  search  queries. 

2.2  Security  with  Search  Queries 

We  propose  a  simulation-based  definition  that  captures  both  ideal 
OPE  security  and  frequency-hiding  even  when  considering  what 
happens  during  the  search  procedure.  Specifically,  we  require  the 
existence  of  a  simulator  simulating  the  view  of  the  protocol  execu¬ 
tion  given  only  a  randomized  order  of  (some  of)  the  plaintexts.  We 
model  this  by  a  random  order  oracle  rord  which  just  takes  the  in¬ 
dices  of  two  data  items  and  returns  which  item  is  larger  according 
to  some  fixed  randomized  order.  Since  the  simulated  view  is  con¬ 
structed  using  only  this  oracle,  the  only  information  leaked  in  the 
real  protocol  corresponds  to  the  oracle  queries  made  to  the  rord 
oracle,  i.e.,  the  randomized  order  on  the  queried  plaintexts. 

To  formalize  the  simulation  tasks,  for  a  sequence  seq  of  inser¬ 
tion  and  search  operations,  we  define  the  profile  profile(seq)  of 
sequence  seq  to  be  a  sequence  where  each  value  in  seq  is  replaced 
with  a  unique  index  (simply  incrementing  starting  from  1)  to  iden¬ 
tify  the  operation.  An  example  sequence  and  its  profile  can  be: 

seq  :  (insert  10,  insert  100,  range  [8,  20],  insert  41). 

profile(seq)  :  (insert  1,  insert  2,  range  [3, 4],  insert  5). 

DEFINITION  1.  A  range  query  protocol  n  is  called  frequency¬ 
hiding  order-preserving ,  for  any  honest-but-curious  server  S,  if 
there  is  a  simulator  Sim  such  that  for  any  sequence  seq  of  inser¬ 
tions  and  searches,  the  following  two  distributions  are  computa¬ 
tionally  indistinguishable: 

VIEWn.s(seq)  R3C  Sim]Iordseqt'’') (profile(seq)), 

where  the  left-hand  side  denotes  the  real  view  of  S  when  executing 
the  protocol  n  with  seq  as  the  client’s  input,  and  the  right-hand 
side  is  the  output  of  the  simulator  Sim  taking  as  input  profile(seq) 
and  referring  to  oracle  rord.  The  oracle  rordseq(-,-)  works  as 
follows: 

rordSeq(i,  j):  It  is  initialized  with  a  randomized  order  n  of  the 
labels  in  seq  by  breaking  ties  randomly.  Then,  for  each  query 
( i,j ),  return  whether  the  ith  label  has  a  higher  ranking  than 
the  j th,  according  to  n. 

Since  the  simulator  refers  to  only  the  profile  and  the  oracle,  we 
can  say  that  for  any  protocol  satisfying  the  above  definition,  the 
protocol  transcript  leaks  to  the  server  only  the  profile  and  the  ran¬ 
domized  order  of  the  queried  plaintexts.  One  benefit  of  this  def¬ 
inition  is  it  covers  both  non-interactive  FH-OPE  schemes  and  our 
interactive  POPE  scheme. 

Leaking  only  a  partial  order.  Recall  that  our  POPE  scheme  grad¬ 
ually  leaks  the  ordering  information  as  more  comparisons  are  made 
in  order  to  execute  the  queries.  To  formally  treat  the  amount  of  in¬ 
formation  that  remains  hidden  after  some  number  of  range  queries, 
we  introduce  a  definition  that  captures  the  number  of  points  that 
remain  incomparable  even  after  some  queries  are  performed. 


First,  we  explain  what  we  mean  by  the  number  of  incomparable 
element  pairs  with  transitivity.  For  example,  consider  a  sequence 
of  four  labels  labels  =  (l\,  £2,  £ 3 ,  if).  There  are  (2)  =  6  initially 
unordered  pairs:  {£1,^2},  {£1,(3},  {£i,£i}^  {£2, £3},  {£2, £4}, 
{£3, £4}.  During  query  execution  the  order  of  some  of  these  pairs 
may  become  known  to  the  server,  i.e.,  if  it  queries  the  rord  oracle 
on  the  indices  of  some  such  pair  or  if  the  order  can  be  inferred  from 
its  previous  queries.  For  example,  given  info  =  (£1  >  £2,  £2  >  £f), 
then  due  to  transitivity,  the  server  can  infer  £\  >  £4.  However,  the 
following  pairs  still  remain  incomparable: 

{^1,^3},  {£2, £3},  {£3, £4} 

Armed  with  this  notion  of  incomparable  pairs  with  transitivity,  we 
give  the  following  definition: 

DEFINITION  2.  Let  n,  m  denote  the  number  of  insertions  and 
range  searches  respectively.  A  range  query  protocol  n  is  frequency¬ 
hiding  partial  order  preserving  with  u  incomparable  element  pairs 
with  transitivity,  if  for  any  operation  sequence  seq  with  n  inserts 
and  m  range  queries,  the  simulator  successfully  creates  a  simu¬ 
lated  view  required  by  Definition  1  while  leaving  at  least  u  pairs 
of  elements  that  are  incomparable  with  transitivity  based  on  the 
queries  made  by  the  simulator  to  rord. 

In  this  paper,  whenever  we  consider  incomparable  pairs,  we  con¬ 
sider  it  with  transitivity,  and  from  now  on,  we  will  omit  the  phrase 
“with  transitivity”.  Note  that  both  the  OPE  scheme  by  Popa  et 
al.  [35]  and  the  FH-OPE  scheme  by  Kerschbaum  [29]  have  0  in¬ 
comparable  element  pairs  for  any  n  inserts,  even  with  0  searches. 
However,  our  POPE  scheme  shows  a  more  gradual  information 
leakage.  We  discuss  this  in  more  detail  in  Section  4. 

3.  MAIN  CONSTRUCTION 
3.1  Overview 

Our  scheme  consists  of  a  client  and  a  server,  which  we  denote  by 
Cl  and  Ser  respectively.  Cl  holds  an  encryption  key  and  performs 
insertions  and  range  query  operations  through  interactive  protocols 
with  Ser.  (In  fact,  only  the  range  query  operation  is  interactive, 
which  is  a  key  benefit  of  our  construction!) 

As  Cl  is  stateless  and  needs  to  remember  nothing  (other  than  the 
secret  key),  all  data  is  stored  encrypted  by  Ser.  To  organize  this 
data  and  facilitate  fast  lookups,  Ser  maintains  a  POPE  tree  to  hold 
the  ciphertexts.  The  high-level  structure  of  this  tree  is  similar  to  a 
B-tree,  where  each  node  has  a  bounded  number  of  children  and  all 
leaf  nodes  are  at  the  same  depth.  In  fact,  the  number  of  children  of 
any  POPE  tree  internal  node  is  between  L/2  +  1  and  L  +  1,  where 
L  is  the  local  temporary  storage  capacity  of  Cl. 

Where  the  POPE  tree  differs  from  a  standard  B-tree  is  that  ev¬ 
ery  node  contains  an  unsorted  buffer  of  ciphertexts  with  unbounded 
size.  The  benefits  of  our  construction,  both  in  terms  of  efficiency 
and  security,  stem  from  the  use  of  these  unsorted  buffers.  For  ef¬ 
ficiency,  they  allow  to  delay  expensive  sorting  and  data  movement 
operations  until  necessary  to  execute  a  range  query.  Security  ben¬ 
efits  stem  from  the  fact  that  the  relative  order  of  elements  in  the 
same  unsorted  buffer  is  not  revealed  to  an  attacker. 

The  insertion  protocol  is  trivial:  Cl  encrypts  the  plaintext  value 
to  be  inserted  and  sends  it  to  Ser,  who  simply  appends  the  new  ci¬ 
phertext  to  the  root  node’s  unsorted  buffer.  Because  semantically 
secure  encryption  is  used,  the  ciphertexts  do  not  reveal  anything 
about  their  true  values  or  order,  not  even  whether  two  inserted  val¬ 
ues  are  the  same  or  different.  All  of  the  actual  sorting  and  ordering 
is  delayed  until  queries  are  performed. 


Before  completing  a  range  query,  Ser  interacts  with  Cl  to  split 
the  tree  according  to  each  of  the  two  query  endpoints.  This  sub¬ 
routine  —  the  most  sophisticated  in  our  entire  construction  —  has 
three  stages.  First,  for  all  the  internal  POPE  tree  nodes  along  the 
search  path  for  the  query  endpoint,  the  unsorted  buffers  are  cleared 
out.  This  clearing  of  the  buffers  proceeds  from  root  to  leaf,  and 
involves  streaming  all  buffer  ciphertexts  back  from  Ser  to  Cl,  who 
responds  for  each  one  with  the  index  of  which  child  node  that  ci¬ 
phertext  should  flow  down  to.  Recall  that  we  maintain  each  internal 
node  having  at  most  L  +  1  children;  this  allows  the  operation  to  be 
performed  efficiently  by  Cl  without  overflowing  the  client’s  size-L 
local  storage. 

This  initial  stage  of  the  split  ends  at  a  leaf  node.  The  second 
stage  involves  reducing  the  size  of  that  leaf  node’s  buffer  to  at  most 
L ,  the  size  of  Cl’s  local  storage.  This  leaf  node  buffer  reduction 
proceeds  by  selecting  L  random  ciphertexts  from  the  leaf  node’s 
buffer,  and  using  Cl  to  split  the  single  leaf  into  L  +  l  new  sibling 
leaf  nodes,  according  to  these  randomly-selected  elements.  These 
L  randomly  sampled  ciphertexts  are  inserted  into  the  parent  node 
as  partition  elements  between  the  new  leaf  nodes.  This  leaf  node 
splitting  procedure  is  repeated  until  the  resulting  leaf  node  has  a 
buffer  of  size  at  most  L. 

However,  we  may  have  inserted  too  many  new  children  into  the 
parent  node,  causing  it  to  have  more  than  the  limit  of  L  +  l  children. 
So  a  rebalance  operation  must  finally  be  completed,  from  the  leaf 
back  up  to  the  root  node,  creating  new  internal  nodes  as  necessary 
until  they  all  have  at  most  L  +  l  children  as  required.  Note  that  this 
stage  does  not  require  any  further  ordering  or  consultation  with  Cl. 

After  performing  this  split  operation  for  both  endpoints,  the  ac¬ 
tual  range  query  can  now  be  completed  by  Ser  returning  to  Cl 
all  the  ciphertexts  in  all  buffers  of  nodes  between  the  two  query 
endpoints.  Again,  this  does  not  require  any  further  ordering  infor¬ 
mation  from  Cl.  Of  particular  importance  for  security  is  that  there 
may  be  large  unsorted  buffers  even  after  the  range  query  completes, 
because  all  contents  of  those  buffers  lie  entirely  within  or  outside 
of  the  desired  range.  The  server  either  returns  all  of  none  of  the 
ciphertexts  in  these  buffers,  but  still  does  not  (and  does  not  need  to) 
learn  their  order. 

Parameters.  Recall  that  the  parameter  n  represents  the  total  num¬ 
ber  of  items  inserted  into  the  database,  and  the  parameter  m  rep¬ 
resents  the  total  number  of  range  query  operations  performed.  The 
client  can  temporarily  store  L  +  0(  1)  labels  in  its  local  memory  for 
the  duration  of  a  given  query.  Let  L  =  n€  for  constant  0  <  e  <  1. 
Notation.  To  support  realistic  application  scenarios,  we  distin¬ 
guish  between  two  types  of  data  that  Ser  holds:  (i)  labels  £  and 
(ii)  blocks  that  are  composed  of  a  POPE-encoded  label  £  and  an 
arbitrary,  encrypted  payload  ve.  This  models  the  case  when  range 
searches  over  POPE-encoded  labels  are  used  to  retrieve  the  pay- 
loads.  No  searching  directly  over  the  payloads  is  supported. 

We  remark  that,  in  principle,  for  every  distinct  label  £,  there 
could  be  many  distinct  blocks  (£,v£1),(£,ve2),...  stored  by  Ser. 
However,  we  will  restrict  to  the  special  case  when  for  each  label  £ 
there  is  at  most  one  block  (£,  ve)  in  order  to  convey  the  main  ideas 
more  clearly.  (Note  this  distinctness  property  holds  w.h.p.  if  we  use 
the  tie-breaking  procedure  described  in  Section  2.1.) 

3.2  Encryption  of  Labels 

In  our  system,  whenever  Cl  communicates  a  label  £  to  Ser  we 
have  Cl  always  send  a  ciphertext  £  to  Ser,  where  £•<—  Enc*,(£). 
Besides  an  encryption  of  the  label  itself,  this  ciphertext  must  also 
encrypt  (a)  the  tie-breaking  random  value  necessary  for  frequency¬ 
hiding  POPE  and  (b)  an  indication  of  the  label’s  origin  (left  or  right 
query  endpoint,  or  insertion). 


Tie-breaking  randomness.  Consider  for  example  that  the  labels 
(1,  2,  2,  3)  have  been  inserted,  followed  by  a  range  query  for  all 
values  between  2  and  3,  requiring  a  total  of  six  encryptions.  From 
Section  2.1,  tie-breaking  randomness  can  be  thought  of  as  adding 
a  random  fractional  part  to  each  plaintext  before  encrypting,  so 
for  example  we  encrypt  the  labels  (1.89,  2.15,  2.35,  3.93)  and  the 
range  query  endpoints  2.23  and  3.38. 

Origin  bits.  This  hides  the  repeated  label  2,  but  creates  a  new 
problem:  the  labels  2.15  and  3.93  which  should  be  included  in  a 
range  search  between  2  and  3,  would  be  excluded  because  of  the 
tie-breaking.  So  we  also  include  two  bits  n  for  the  origin  of  the 
plaintext:  7t;  =  00  and  nr  =  11  for  left  and  right  query  endpoints 
respectively,  and  n m  =  01  for  an  insertion.  These  bits  are  inserted 
between  the  actual  label  and  the  tie-breaking  values,  so  (contin¬ 
uing  the  previous  example),  we  would  insert  the  encryptions  of 
(1.01.89,  2.01.15,  2.01.35,  3.01.93)  and  query  endpoints  2.00.23 
and  3.11.38.  This  forces  the  range  search  to  return  the  three  correct 
values. 

Two-block  ciphertexts.  Even  treating  the  two  origin  bits  as  part  of 
the  label,  each  plaintext  becomes  two  blocks  long,  so  that  a  straight¬ 
forward  application  of  CTR  or  CBC  mode  encryption  results  in 
ciphertexts  of  three  blocks.  One  can  achieve  better  efficiency  by 
not  including  the  tie-breaking  randomness  but  still  enabling  the  re¬ 
ceiver  to  compute  it.  In  particular,  let  /  be  a  PRP,  and  let: 

•  encfc(m||7r):  Choose  a  random  string  r.  Return  the  pair 
(r,  fk(r  -I-  l)®(m||7r)). 

•  decj,(ci,  C2):  Compute  m\\n  +-  fk(c\  +  1)®C2  and  the  tie 
breaking  randomness  u<—  fk  (ci  +  2).  Return  (m,  n,  u). 

Note  it’s  just  the  CTR  mode  of  encryption.  Even  though  the 
ciphertext  doesn’t  explicitly  contain  the  tie-breaking  randomness, 
the  reconstructed  it  serves  for  this  purpose. 

3.3  Server  Memory  Layout 

Ser  statefully  maintains  the  POPE  tree  T,  which  is  a  balanced 
L-ary  tree  with  root  r. 

•  Each  non-leaf  node  it  G  T  stores  a  buffer  and  a  list. 

•  Each  leaf  node  u  G  T  stores  a  buffer  only. 

A  buffer  stores  an  unbounded,  unsorted  set  of  (encryptions  of) 
blocks  {(£\ ,  vi^ ),  (£2,ve2),  •■},  and  a  list  stores  at  most  L  sorted 
(encryptions  of)  labels  (£1, ...,  £if). 

Main  invariant  of  the  POPE  tree  T.  We  will  enforce  the  follow¬ 
ing,  main  order-invariant  on  Ser’s  tree  T : 

Let  £j-i  and  £j  be  the  ( j  —  l)th  and  jth  sorted  labels  at  some 
(non-leaf)  node  u  in  T.  Then,  for  all  labels  £  in  the  sub-tree  Tu. 
rooted  at  the  jth  child  Uj  of  it,  we  have  £j-i  <  £  <  £j. 

Intuitively,  this  guarantee  of  global  partial  ordering  enables  the  L 
sorted  labels  £i,...,£l  at  each  node  u  to  serve  as  an  array  of  si¬ 
multaneous  pivot  elements ,  in  the  sense  of  Quicksort  [28],  for  the 
L  +  l  sub-trees  rooted  at  it’s  (at  most)  L  +  l  children  it  1, ...,  ul+ i- 
Looking  ahead,  we  use  this  simple,  parallel  pivot  idea  in  conjunc¬ 
tion  with  the  parameter  setting  L  =  n£,  implying  T  has  depth 
[1/e]  =  0(1),  to  enable  Ser  to  traverse  and  maintain  the  tree  T 
with  low  amortized  latency  over  repeated  batches  of  Cl  queries. 

3.4  The  POPE  Protocol 

We  now  present  more  formally  our  protocol  POPE  consisting  of 
three  operations:  Setup,  Insert,  and  Search.  The  Search  protocol 
results  in  additional  calls  to  helper  protocols  Split  and  Rebalance, 
described  afterward. 


Implementing  Setup.  At  Setup,  Cl  and  Ser  do: 


Setup: 

-  Cl  generates  private  keys  for  label/block  encryption. 
-Ser  initializes  1~  as  a  root  r  with  empty  buffer  and  list. 


Implementing  Insert.  To  Insert  a  block  (£,  v).  Cl  and  Ser  do: 


Insert  (£,  v): 

-  Cl  sends  (encrypted)  block  (£,  v)  to  Ser. 

-  Ser  appends  block  (£,  v)  to  the  end  of  the  current  root  node’s  buffer. 

After  Setup  and  possibly  many  Insert  operations  (but  no  Search 
operations),  the  POPE  tree  T  held  by  Ser  appears  as  in  Figure  3. 


Figure  3:  The  state  of  Ser’s  tree  T  prior  to  any  Search  queries. 


Implementing  Search.  For  Cl  to  Search  for  the  range  of  blocks 
held  by  Ser  in  T  between  two  labels  £|eft  and  Aight,  Cl  and  Ser  do: 

Search  (^ieft 5 bright)- 

-  Cl  and  Ser  engage  in  an  interactive  protocol  Split  twice, 

once  for  £|eft  and  once  for  ^rjght- 

-  After  each  Split,  Cl  identifies  for  Ser  the  leaf  node 

ifieft  (or  bright)  in  that  matches  the  label  £|eft  (or  flight)- 

-  Ser  sends  the  blocks  in  [u|eft,  bright]  to  Cl. 


How  to  Split  the  POPE  Tree.  For  Cl  to  Split  Ser’s  tree  T  at  label 
l  £  {^left,  bright},  Cl  and  Ser  engage  in  an  interactive  protocol.  This 
operation  will  return  the  leaf  node  whose  buffer  contains  the  given 
label  with  the  guarantee  that  all  nodes  along  the  path  from  the  root 
to  that  leaf  have  empty  buffers. 

Individual  Split  calls  always  begin  at  the  current  root  r  £  T. 
After  any  (non-leaf)  node  u  £  T  is  split,  Ser  learns  (from  Cl) 
the  index  i  £  [L  +  1]  of  the  next  child  Ui  of  u  to  be  Split.  The 
Split  protocol  proceeds  recursively  down  some  path  of  T,  splitting 
subsequent  children  ...  until  terminating  at  a  leaf  node  u. 

(For  readability  in  what  follows,  we  assume  that  Ser  always  returns 
whole  nodes  to  Cl  for  each  Search  response.) 

We  break  our  description  of  Split  into  two  broad  cases:  (i)  the 
Splits  of  internal,  i.e.,  non-leaf  nodes,  and  (ii)  the  Splits  of  leaf 
nodes. 

Case  (i)  —  Splits  at  internal  nodes:  For  splits  at  internal  nodes  u 
with  children  denoted  m.  Cl  and  Ser  do: 

Split  (t)  — for  internal  nodes  u: 

-  Ser  sends  £  =  u.list  to  Cl. 

-  Ser  streams  v')  £  u. buffer  to  Cl. 

-  Cl  sends  the  sorted  index  i  £  [L  +  1] 
of  each  (if  v')  in  £  to  Ser. 

-  Ser  appends  block  (if  v')  to  u,  .buffer 


During  this  operation.  Cl  either  (a)  sees  the  searched-for  label 
£  £  {£|eft,  -fright}  (and  discovers  node  m  to  proceed  to),  or  (b)  dis¬ 


covers  the  node  u;  that  may  contain  label  £  based  on  its  boundary 
values. 

The  block  movement  in  splits  at  internal  nodes  is  illustrated  in 
Figure  4.  (The  outcomes  of  three  “splits”  are  shown.) 


Figure  4:  The  flow  of  blocks  in  recursive  Split's  of  Ser’s  tree  T. 


Case  (ii)  —  Splits  at  the  leaves:  For  splits  at  leaf  node  u  with 
parent  node  u* ,  Cl  and  Ser  do: 

Split  (£)  — for  leaf  nodes  u: 

-If  |u.buffer|  <  L.  return. 

-  Ser  samples  L  labels  £  =  {£i ,  ...,£z,}  from  u. buffer. 

-  Ser  creates  new  root  u*  if  u  is  the  root  node,  or  sets  u*  to 

u’s  parent  otherwise. 

-  Ser  sends  £  to  Cl. 

-  Cl  sorts  £  and  returns  it  to  Ser. 

-  Ser  inserts  L  new  sibling  leaf  nodes  Ui  into  parent  u* 

as  well  as  new  labels  £  into  u*  .list  at  the  position  previously 
occupied  by  u  (node  u  is  deleted  after  it  is  split). 

-  Ser  streams  (If  v')  £  u. buffer  to  Cl 

-  Cl  sends  the  sorted  index  i  £  \L  +  1] 
of  each  (If  v’)  in  u.  buffer  to  Ser. 

-  Ser  inserts  block  iff  v')  into  sibling  node  Uj 

-  Cl  indicates  to  Ser  the  index  i  of  new  leaf  node  matching  l 


Note  that  if  the  size  of  the  buffer  is  smaller  than  the  local  storage 
capacity  L  of  Cl,  then  this  operation  does  nothing,  and  the  split  is 
complete.  Otherwise,  as  in  Case  (i)  of  Split,  Cl  will  learn  which  of 
the  sibling  leaf  nodes  u;  to  recursively  Split  in  order  to  find  label 
£.  In  this  way,  a  single  Split  operation  may  recursively  result  in 
multiple  leaf  node  Split’s,  with  smaller  and  smaller  buffers. 

As  an  example,  the  new  state  of  Ser’s  tree  T  immediately  after 
Cl’s  first  Split  call  (which  splits  the  starting  leaf  node  of  T,  i.e.  the 
root)  is  as  depicted  in  Figure  5. 

Clean-up  Step:  Rebalancing  a  Split  POPE  Tree.  After  complet¬ 
ing  the  Split  protocol  above,  the  resulting  leaf  node  at  which  Split 
terminates  will  have  size  at  most  L,  but  some  internal  node’s  sorted 
list  may  be  larger  than  L  because  of  the  insertions  from  their  chil¬ 
dren  —  see  case  (ii)  of  Split.  This  would  be  problematic  in  future 
Split  operations  on  those  internal  nodes,  as  they  would  send  u.list 
to  Cl,  who  only  has  room  for  L  items. 


4.2  Security  Analysis 


Figure  5:  The  state  of  Ser’s  tree  T  after  the  very  first  Split  ends:  the  new 
root  r  :=  u*  (empty  buffer,  full  list),  plus  L  +  1  leaves. 


To  fix  this,  after  completing  the  Split  protocol,  Ser  calls  the  fol¬ 
lowing  operation  on  the  parent  of  the  resulting  leaf  node  in  order  to 
rebalance  the  labels  in  the  lists  of  the  internal  nodes.  We  empha¬ 
size  that  Rebalance  is  purely  a  local  data  structure  manipulation, 
and  does  not  require  interaction  from  Cl,  since  the  unsorted  buffer 
of  the  rebalanced  nodes  is  empty  due  to  prior  Split,  having  only 
sorted  labels  in  the  list. 

More  concretely,  to  Rebalance  at  node  u  (initially  the  parent  of 
the  leaf  where  Split  ended),  Ser  does: 

Rebalance(u): 

-  If  |u.list|  <  L,  return. 

-  If  u  has  no  parent  u* .  create  a  fresh  root  node  r  for  T 

and  set  u*  :=  r. 

-  Partition  v/.list  into  sorted  sublists  of  size  at  most  L  each  by  selecting 

C  =  [every  ( L  +  l)'th  element  in  u.list], 

-  Create  |£|  new  sibling  nodes  and  insert  them  as  well  as  the  new  labels 

C  into  parent  node  u* . 

-  Call  Rebalance^*). 

This  completes  the  description  of  our  main  POPE  protocol. 

4.  ANALYSIS 
4.1  Cost  Analysis 

We  analyze  amortized  costs  on  the  round  complexity  and  band¬ 
width  per  operation. 

THEOREM  1.  After  n  insertions  and  m  query  operations  with 
local  storage  of  size  L,  our  scheme  has  the  following  costs: 

1.  Insert  always  requires  a  single  round,  and  Search  requires 
0( logL  n )  rounds  in  expectation. 

2.  The  total  expected  bandwidth  over  all  (n  +  m)  operations 
(excluding  the  bandwidth  necessary  for  sending  the  search 
results)  is 

O  ( ml  \ogLn  +  nlogLm  +  n\ogL(lgn)). 

The  proof  is  found  in  Appendix  A. 

Remark.  With  L  =  ne,  0  <  e  <  1,  Theorem  1  implies  that 
Search  takes  0(1)  rounds  in  expectation.  Moreover,  when  L  =  ne 
and  m  =  0(n1_£)  as  well,  the  amortized  bandwidth  per  opera¬ 
tion  becomes  0(1).  This  is  exactly  our  target  scenario  of  many 
insertions  and  relatively  few  searches. 


THEOREM  2.  The  POPE  protocol  is  a  frequency-hiding  order¬ 
preserving  range  query  protocol. 

PROOF.  We  show  that  our  POPE  scheme  satisfies  Definition  1 
by  showing  a  simulator.  The  simulator  is  very  simple.  For  each 
insert,  the  simulator  sends  enCfc(O);  due  to  semantic  security  of  the 
underlying  encryption,  the  simulation  is  indistinguishable.  To  sim¬ 
ulate  search  queries,  the  simulator  runs  the  adversarial  server’s  al¬ 
gorithm,  and  during  the  simulation,  when  the  server  needs  to  com¬ 
pare  two  encrypted  labels,  the  simulator  simply  queries  the  rord 
oracle  to  get  the  answer.  It’s  obvious  that  the  simulated  view  is 
indistinguishable  to  the  real  view  of  the  server.  ■ 

Security  with  queries.  Range  query  schemes  leak  some  informa¬ 
tion  of  underlying  plaintexts  from  adaptive  search  queries.  In  this 
case,  one  important  security  measure  can  be  the  number  of  pairs  of 
incomparable  elements.  In  any  range  query  scheme,  search  queries 
reveal  some  partial  order  on  the  underlying  plaintexts.  Recall  that 
a  partial  order  -<  on  a  set  of  elements  S  is  isomorphic  to  a  directed 
acyclic  graph,  closed  under  transitive  closure,  whose  nodes  are  el¬ 
ements  of  S  and  whose  edges  encode  the  binary  relation.  A  total 
order  on  n  items  always  has  Q)  edges.  In  any  partial  order,  two 
elements  x,y  £  S  are  said  to  be  incomparable  iff  neither  x  A  y 
nor  y  A  x.  In  a  total  order  (such  as  the  randomized  order  of  [29]), 
no  pair  of  elements  is  incomparable.  In  our  POPE  scheme,  each 
search  query  gradually  leaks  the  ordering  information  of  the  un¬ 
derlying  plaintexts.  In  particular,  with  a  small  number  of  search 
queries,  there  will  be  many  pairs  of  incomparable  elements. 

THEOREM  3.  After  n  insertions  and  m  query  operations  with 
local  storage  of  size  L,  where  mL  £  o(n),  our  POPE  scheme  is 

frequency-hiding  partial -order-preserving  with  PI  ^  mL 
incomparable  pairs  of  elements. 

PROOF.  Note  the  simulator  in  the  above  proof  uses  oracle  rord 
whenever  the  server  algorithm  needs  to  compare  the  elements.  So, 
we  can  prove  the  theorem  by  using  a  counting  argument  on  the 
number  of  labels  that  the  server  compares.  We  model  the  server’s 
view  of  the  ciphertext  ordering  as  some  k  ciphertexts  whose  order 
is  completely  known,  and  where  the  remaining  n  —  k  ciphertexts 
are  partitioned  into  one  of  k  +  1  buckets  according  to  the  k  ordered 
ciphertexts.  Essentially,  this  is  a  worst-case  scenario  where  all  in¬ 
ternal  node  buffers  in  the  POPE  tree  are  empty,  the  total  size  of  all 
internal  node  sorted  lists  is  k,  and  the  remaining  n  —  k  ciphertexts 
reside  in  leaf  node  buffers. 

We  focus  on  the  round  complexity  for  range  queries  (insertion 
gives  no  change  in  the  number  of  comparable  elements).  From 
Theorem  1,  the  total  rounds  of  communication  for  range  queries, 
after  n  insertions  and  m  range  queries,  is  0(m  logL  n).  From  the 
construction,  each  round  of  communication  can  add  at  most  L  new 
ciphertexts  to  those  whose  sorted  order  is  completely  known. 

Therefore,  in  the  worst  case,  the  server  has  k  =  OfmL  logL  n) 
ciphertexts  in  its  sorted  order,  creating  k  +  1  buckets  in  which 
the  other  values  are  placed.  Thus,  the  worst-case  split  that  mini¬ 
mizes  the  total  number  of  incomparable  elements  is  for  the  remain¬ 
ing  values  to  be  partitioned  equally  among  these  buckets.  Thus, 
we  have  b  =  [(n  —  k)/(k  +  1)J  ciphertexts  in  each  unsorted 
bucket.  Each  bucket  contains  ((()  incomparable  items,  for  a  total 
of  (k  +  1)  •  (*)  =  fi(^ - n)  incomparable  pairs.  ■ 

Privacy  against  a  malicious  server.  Note  the  above  theorem 
considers  the  worst  case.  This  implies  we  can  easily  achieve  pri¬ 
vacy  against  a  malicious  server  with  tiny  additional  costs,  that  is, 


by  making  sure  that  ( 1 )  all  the  ciphertexts  that  the  server  asks  the 
client  to  compare  are  legitimate,  that  is,  created  by  the  client  (to  en¬ 
sure  this,  the  labels  should  now  be  encrypted  with  IND-CCA2  en¬ 
cryption).  and  (2)  the  number  of  the  server’s  comparison  requests 
should  be  within  the  bounds  of  Theorem  1 . 

Unfortunately,  this  augmented  system  doesn’t  achieve  full  ma¬ 
licious  security;  in  particular,  a  malicious  server  may  omit  some 
values  from  the  query  answers,  although  it  cannot  inject  a  fake  re¬ 
sult  due  to  IND-CCA2  security  of  the  underlying  encryption.  Ef¬ 
ficiently  achieving  full  malicious  security  is  left  as  an  interesting 
open  problem. 

5.  EVALUATION 

5.1  Experimental  setup 

We  have  made  a  proof-of-concept  implementation  of  our  POPE 
scheme  in  order  to  test  the  practical  utility  of  our  new  approach. 
The  code  is  written  in  Python3  and  our  tests  were  performed  using  a 
single  core  on  a  machine  with  an  Intel  Xeon  E5-2440  2.4  GHz  CPU 
and  72GB  available  RAM.  Our  implementation  follows  the  details 
presented  in  Section  3.  The  symmetric  cipher  used  is  128-bit  AES, 
as  provided  by  the  PyCrypto  library.  The  full  source  code  of  our 
implementation  is  available  at  https://github.com/dsroche/pope. 
Database  size.  While  we  performed  experiments  on  a  wide  range 
of  database  sizes  and  number  of  range  queries,  our  "typical”  start¬ 
ing  point  is  one  million  insertions  and  one  thousand  range  queries. 
This  is  the  same  scale  as  recent  work  in  the  databases  community 
for  supporting  range  queries  on  outsourced  data  [31],  and  would 
therefore  seem  to  be  a  good  comparison  point  for  practical  pur¬ 
poses. 

Parameters.  In  our  experiments,  we  varied  the  total  database  size 
between  one  thousand  and  100  million  entries,  each  time  perform¬ 
ing  roughly  m  =  n1^2  range  queries  and  with  L  =  n1/4  local 
client  storage.  That  is,  e  =  0.25  in  these  experiments.  The  size  of 
each  range  being  queried  was  randomly  selected  from  a  geometric 
distribution  with  mean  100;  that  is,  each  range  query  returned  on 
average  100  results. 

Network.  Our  main  experiments  were  performed  in  a  local  setup, 
but  with  careful  measurement  of  communication  and  under  the  as¬ 
sumption  that  network  bandwidth  (i.e.,  amortized  communication 
size)  and  latency  (i.e.,  round  complexity)  would  be  the  bottlenecks 
of  a  remote  cloud  implementation.  In  particular,  in  our  network 
experiments,  we  used  the  tc  “traffic  control”  utility  to  add  specific 
latency  durations  as  well  as  bandwidth  limitations.  This  allowed 
us  to  test  the  behavior  under  controlled  but  realistic  network  set¬ 
tings,  when  we  throttled  the  network  slower  than  5ms  of  latency 
and  20Mbps  bandwidth. 

Comparison  with  Popa  et  al.  We  compared  our  construction  ex¬ 
perimentally  to  that  of  Popa  et  al.  [35],  who  had  a  setting  most 
similar  to  ours.  Further  comparison  benchmarks,  such  as  to  [30]  or 
even  to  ORAMs,  might  provide  further  insight,  and  we  leave  this 
as  future  work. 

For  a  fair  comparison  to  prior  work,  we  also  implemented  the 
mOPE  scheme  of  [35]  in  Python3  along  with  our  implementation 
of  POPE.  We  followed  the  description  in  their  work,  using  a  B-tree 
with  at  most  4  items  per  node  to  store  the  encryptions.  To  get  a 
fair  comparison,  we  used  the  same  framework  as  our  POPE  experi¬ 
ments,  with  the  client  that  receives  sorting  and  partitioning  requests 
from  the  server.  In  the  case  of  mOPE,  each  round  of  communica¬ 
tion  consisted  of  sending  a  single  B-tree  node’s  worth  of  cipher- 
texts,  along  with  one  additional  ciphertext  to  be  encoded,  and  re¬ 
ceiving  the  index  of  the  result  within  that  sorted  order.  We  acknowl¬ 


edge  that  our  implementation  is  likely  less  tuned  for  efficiency  than 
that  of  the  original  authors,  but  it  gives  a  fair  comparison  to  our 
own  implementation  of  POPE.  It  is  also  important  to  note  that  our 
communication  cost  measurements  depend  only  on  the  algorithm 
and  not  on  the  efficiency  of  the  implementation. 

Measuring  communication  and  running  time.  When  our  tests 
measured  communication  (in  terms  of  rounds  and  total  ciphertexts 
transferred)  and  running  time,  we  did  not  include  the  cost  of  the 
server  sending  the  search  results;  this  is  inherent  in  the  operation 
being  performed  and  would  be  the  same  for  any  alternative  imple¬ 
mentation. 

5.2  Experimental  workloads 

Local  setting:  huge  data,  various  search  patterns.  In  our  main 
experiments,  where  we  wanted  to  scale  the  number  of  database  en¬ 
tries  from  one  thousand  up  to  100  million  entries,  we  used  synthetic 
data  consisting  of  random  pairs  of  English  words  for  both  label  and 
payload  values.  For  these  experiments  we  also  did  not  actually 
transfer  the  data  over  a  network,  but  merely  measured  the  theo¬ 
retical  communication  cost.  This  allowed  us  to  test  a  much  wider 
range  of  experimental  sizes,  as  we  found  a  roughly  lOx  slowdown 
in  performance  when  running  over  a  network,  even  with  no  throt¬ 
tling  applied. 

The  actual  size  of  each  range  being  searched  was.  on  average, 
100  database  entries.  While  the  distribution  of  searches  does  not 
affect  the  running  time  of  mOPE.  for  POPE  we  varied  among  three 
distributions  of  the  random  range  queries:  (i)  uniformly  distributed 
queries,  (ii)  search  queries  all  “bunched”  at  the  end  after  all  in¬ 
sertions,  (iii)  a  single,  repeated  query,  performed  at  random  inter¬ 
vals  among  the  insertions.  According  to  our  theoretical  analysis, 
the  "bunched”  distribution  should  be  the  worst-case  scenario  and 
the  repeated  query  should  be  the  best-case.  In  practice  we  did  not 
see  much  difference  in  performance  between  bunched  or  random 
queries,  though  as  expected,  we  observed  improved  performance 
for  the  repeated  query  case. 

Networked  setting:  real  salary  data.  To  test  performance  over  a 
realistic  network  with  latency  and  bandwidth  restrictions,  we  used 
the  California  public  employee  payroll  data  from  2014,  available 
from  [1],  as  a  real  dataset  on  which  to  perform  additional  experi¬ 
ments.  This  dataset  lists  payroll  information  for  roughly  2.3  mil¬ 
lion  public  employees.  We  used  the  total  salary  field  as  our  “label” 
value  (on  which  range  queries  are  performed),  and  the  names  as  the 
payload  values. 

We  were  not  able  to  complete  any  test  runs  of  the  mOPE  using 
actual  network  communication  over  the  salary  dataset;  based  on 
partial  progress  in  our  experiment  we  estimate  it  would  take  several 
days  to  complete  just  one  test  run  of  this  experiment  using  mOPE 
and  actual  network  communication  with  our  Python  implementa¬ 
tion. 

We  were  able  to  run  experiments  with  POPE  up  to  100  million 
entries,  limited  only  by  the  storage  space  available  on  our  test  ma¬ 
chine.  We  observed  no  significant  change  in  per-operation  perfor¬ 
mance  after  one  million  entries,  indicating  our  construction  should 
scale  well  to  even  larger  datasets. 

5.3  Local  Setting 

Experimental  communication  costs.  Figures  6  and  7  show  the 
communication  costs,  the  total  number  of  rounds  of  communica¬ 
tion,  and  the  average  number  of  ciphertexts  transferred  per  opera¬ 
tion.  The  number  of  insertions  n  is  shown  in  the  plots,  and  for  each 
experiment  we  performed  m  =  \Jn  searches  allowing  L  =  n1' 4 
entries  stored  in  temporary  memory  on  the  client. 
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Figure  6:  Total  rounds  of  communication  for  POPE  and  mOPE,  plotted  in  Figure  8:  Operations  performed  per  second  for  POPE  and  mOPE.  Higher 

log/log  scale  according  to  total  number  of  insertions  n.  Lower  is  better.  The  is  better.  The  number  of  range  queries  in  all  cases  was  yfn. 
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Figure  7 :  Amortized  communication  costs  for  POPE  and  mOPE,  according 
to  total  number  of  insertions  n.  Lower  is  better.  The  number  of  range 
queries  in  all  cases  was  y/n. 
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Figure  9:  Degradation  in  POPE  performance  with  increasing  number  of 
queries,  measured  in  operations  per  second.  Higher  is  better.  In  all  experi¬ 
ments,  the  number  of  insertions  n  was  fixed  at  1  million,  and  the  client-side 
storage  at  L  =  32.  For  these  choices,  2 1 11  rs  y/n  queries  is  as  shown  in 
prior  figures,  and  our  0(l)-cost  analysis  holds  uptomfs  215. 


As  these  figures  demonstrate,  the  round  complexity  for  POPE, 
which  is  constant  per  range  query,  is  several  orders  of  magnitude 
less  than  that  of  mOPE.  Furthermore,  when  averaged  over  all  op¬ 
erations,  the  number  of  ciphertexts  transferred  per  operation  for 
POPE  is  roughly  7  in  the  worst  case,  whereas  for  mOPE  this  in¬ 
creases  logarithmically  with  the  database  size. 

Experimental  running  time.  The  per-second  operations  counts, 
for  our  main  experiments  with  n  insertions,  m  =  y/n  range  queries, 
and  L  =  n1^4  client-side  storage,  are  presented  in  Figure  8.  For 
POPE,  the  performance  increases  until  roughly  1  million  entries, 
after  which  the  per-operation  performance  holds  steadily  between 
50,000  operations  per  second  with  random,  distinct  queries,  and 
110,000  operations  per  second  with  a  single,  repeated  query. 

For  one  million  entries  and  using  our  Python  implementation 
without  parallelization,  we  achieved  over  55,000  operations  per 
second  with  POPE  vs.  less  than  2,000  operations  per  second  for 
mOPE,  without  even  accounting  for  the  network  communication. 

Our  POPE  construction  is  well-suited  particularly  for  problems 
with  many  more  insertions  than  range  queries;  indeed,  the  0(1) 
theoretical  performance  guarantees  hold  only  when  mL  <  n.  Fig¬ 
ure  9  shows  the  effects  of  varying  numbers  of  range  queries  on 
POPE  performance.  Although  the  performance  of  POPE  clearly 
degrades  with  increasing  numbers  of  queries  performed,  this  ex¬ 
periment  shows  competitive  performance  compared  to  mOPE  even 
when  m  =  n. 


5.4  Experimental  Network  Effects 

We  tested  the  effects  of  varying  network  latency  and  bandwidth 
using  the  California  public  employees  payroll  data  as  described 
above.  Our  workload  consisted  of  all  2,351,103  insertions  as  well 
as  1.000  random  range  queries  at  random  points  throughout  the  in¬ 
sertions.  Each  range  query  result  size  was  fixed  at  100  entries. 

Figure  10  shows  the  effects  of  latency  on  the  POPE  implemen¬ 
tation.  With  less  than  5ms  of  latency,  the  cost  is  dominated  by  that 
of  the  POPE  computation  and  other  overhead.  Beyond  this  level, 
the  total  runtime  scales  linearly  with  the  latency.  Note  that  10ms 
to  30ms  represents  typical  server  response  times  within  the  same 
continent  over  the  Internet. 

Figure  1 1  shows  the  effects  of  bandwidth  limitations  on  our  con¬ 
struction.  Without  any  latency  restriction,  we  limited  the  band¬ 
width  between  1  and  20  megabits  per  second  (Mbps),  which  is  the 
typical  range  for  4G  (on  the  low  end)  and  home  broadband  Inter¬ 
net  (on  the  high  end)  connections.  We  can  see  that,  past  roughly  10 
Mbps,  the  other  overhead  of  the  implementation  begins  to  dominate 
and  there  is  no  more  significant  gain  in  speed. 

6.  RELATED  WORK 

Order-Preserving  and  Order-Revealing  Encryption.  Order- 
preserving  encryption  (OPE)  [3,  7,  8]  guarantees  that  enc(x)  < 
enc(y)  iff  x  <  y.  Thus,  range  queries  can  be  performed  directly 
over  the  ciphertexts  in  the  same  way  that  such  a  query  would  be 


induced  network  latency  (ms) 

Figure  10:  Total  running  time  for  2.3  million  insertions  and  1000  random 
range  queries,  running  over  a  network  with  varying  artificially-induced  la¬ 
tency  times. 


Figure  11:  Total  running  time  for  2.3  million  insertions  and  1000  random 
range  queries,  running  over  a  network  with  varying  bandwidth  limitations. 


performed  over  the  plaintext  data.  However,  OPE  comes  with  a 
security  cost.  None  of  the  original  schemes  [3,  7]  achieve  the 
ideal  security  goal  for  OPE  of  IND-OCPA  (indistinguishability  un¬ 
der  ordered  chosen-plaintext  attack)  [7]  in  which  ciphertexts  reveal 
no  additional  information  beyond  the  order  of  the  plaintexts.  In 
fact  Boldyreva  et  al.  [7]  prove  that  achieving  a  stateless  encryp¬ 
tion  scheme  with  this  security  goal  is  impossible  under  reasonable 
assumptions.  The  existing  schemes,  instead,  either  lack  formal 
analysis  or  strive  for  weaker  notions  of  security  which  have  been 
shown  to  reveal  significant  amount  of  information  about  the  plain¬ 
text  [8],  The  first  scheme  to  achieve  IND-OCPA  security  was  the 
order-preserving  encoding  scheme  of  Popa  et  al.  [35], 

A  related  primitive  to  OPE  is  order-revealing  encryption  (ORE) 
[7],  which  provides  a  public  mechanism  for  comparing  two  en¬ 
crypted  values  and  thus  also  enables  range  searches  over  encrypted 
data.  (Note,  OPE  is  the  special  case  where  this  mechanism  is  lex¬ 
icographic  comparison,)  The  first  construction  of  ORE  satisfying 
ideal  security  [10]  was  based  on  multi-linear  maps  [20]  and  is  thus 
unlikely  to  be  practical  in  the  near  future.  An  alternative  scheme 
based  only  on  pseudorandom  functions  [15],  however,  has  addi¬ 
tional  leakage  that  weakens  the  achieved  security. 

OPE  alternatives.  In  addition  to  OPE  there  are  several  other  lines 
of  work  that  enable  searching  over  encrypted  data.  Typically,  these 
works  provide  stronger  security  than  provided  by  OPE;  in  particu¬ 
lar  they  do  not  reveal  the  full  order  of  the  underlying  data  as  hap¬ 
pens  with  OPE.  However,  the  additional  security  guarantees  come 
at  a  significant  performance  cost  with  even  the  latest  schemes  being 
one  to  two  orders  of  magnitude  slower  than  the  latest  OPE-based 
implementations  [34,  19]. 


Symmetric  searchable  encryption  (SSE)  was  first  proposed  by 
Song,  Wagner,  and  Perrig  [39]  who  showed  how  to  search  over 
encrypted  data  for  keyword  matches  in  sub-linear  time.  The  first 
formal  security  definition  for  SSE  was  given  by  Goh  [23],  Curt- 
mola  et  al.  [16]  showed  the  first  SSE  scheme  with  sublinear  search 
time  and  compact  space,  while  Cash  et  al.  [13]  showed  the  first  SSE 
scheme  with  sublinear  search  time  for  conjunctive  queries.  Recent 
works  [34,  13,  19]  achieve  performance  within  a  couple  orders  of 
magnitude  of  unencrypted  databases  for  rich  classes  of  queries  in¬ 
cluding  boolean  formulas  over  keyword,  and  range  queries.  Of  par¬ 
ticular  interest  is  the  work  of  Hahn  and  Kerschbaum  [27]  who  show 
how  to  use  lazy  techniques  to  build  SSE  with  quick  updates.  We 
refer  interested  readers  to  the  survey  by  Bosch  et  al.  [12]  for  an 
excellent  overview  of  this  area. 

Oblivious  RAM  [24,  38,  40,  44]  and  oblivious  storage  schemes 
[26,  4,  18,  32]  can  be  used  for  the  same  applications  as  OPE  and 
POPE,  but  achieve  a  stronger  security  definition  that  additionally 
hides  the  access  pattern,  and  therefore  incur  a  larger  performance 
cost  than  our  approach. 

Finally,  we  note  that  techniques  such  as  fully-homomorphic  en¬ 
cryption  [22],  public-key  searchable  encryption  [9,  11,  37],  and 
secure  multi-party  computation  [46,  6,  25]  can  enable  searching 
over  encrypted  data  while  achieving  the  strongest  possible  security. 
However,  these  approaches  would  require  performing  expensive 
cryptographic  operations  over  the  entire  database  on  each  query 
and  are  thus  prohibitively  expensive.  Very  recently  cryptographic 
primitives  such  as  order-revealing  encryption  [10],  as  well  as  gar¬ 
bled  random-access  memory  [21],  have  offered  the  potential  to 
achieve  this  level  of  security  for  sub-linear  time  search.  However, 
all  constructions  of  these  primitive  either  rely  on  very  non-standard 
assumptions  or  are  prohibitively  slow. 

Lazy  data  structures  and  I/O  complexity.  Our  POPE  tree  is  is 
similar  in  concept  to  the  Buffer  Tree  of  [5],  Their  data  structure  de¬ 
lays  insertions  and  searches  in  a  buffer  stored  at  each  node,  which 
are  cleared  (thus  executing  the  actual  operations)  when  they  be¬ 
come  sufficiently  full.  The  main  difference  here  is  that  our  buffers 
contain  only  insertions,  and  they  are  cleared  only  when  a  search 
operation  passes  through  that  node. 

We  also  point  out  an  interesting  connection  to  I/O  complexity 
regarding  the  size  of  local  storage.  In  our  construction,  as  in  [36], 
the  client  is  treated  as  an  oracle  to  perform  comparisons  of  cipher- 
texts.  If  we  think  of  the  client’s  memory  as  a  “working  space”  of 
size  L,  and  the  server’s  memory  as  external  disk,  then  from  [2]  it 
can  be  seen  that  performing  m  range  queries  on  a  database  of  size 
n  >  m  requires  a  total  transfer  bandwidth  of  at  least  0(m  logL  m) 
ciphertexts.  (This  is  due  to  the  lower  bound  on  the  I/O  complexity 
of  sorting,  and  the  fact  that  m  range  queries  can  reveal  the  order 
of  a  size-m  subset.)  In  particular,  this  means  that  the  mOPE  con¬ 
struction  from  [36]  cannot  be  improved  without  either  limiting  the 
number  of  queries,  or  increasing  the  client-side  storage,  both  of 
which  we  do  for  POPE. 
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APPENDIX 

A.  PROOF  OF  THEOREM  1 

Choose  n,  t  so  that  L  =  ne  >  16.  The  case  of  Insert  is  trivial 
to  analyze:  The  server  never  makes  comparison  requests.  So.  we 
focus  on  the  case  of  Search. 

An  alternative  split  procedure  To  simplify  our  analysis,  we  in¬ 
troduce  an  alternative  version  of  the  leaf  splitting  procedure  which 
discards  any  split  that  results  in  very  unbalanced  partitions.  We  ar¬ 
gue  that  such  a  split  will  always  (in  expectation)  be  worse  than  our 
original  split  and  thus  can  be  used  to  bound  its  costs. 

Let  z  =  2L/\ogL.  We  say  that  a  set  of  L  pivot  points  is  2- 
balanced  if  there  are  2  (out  of  L )  pivots  such  that  partitioning  a 
node  of  size  k  using  these  2  pivots  only  results  in  partitions  that  are 
each  of  size  at  most  2k/ z. 

A.  As  in  actual  Split,  choose  L  pivots  uniformly  at  random  and  par¬ 
tition  the  labels  according  to  these  pivots. 

B.  If  the  L  pivots  are  not  2-balanced,  throw  out  the  partition  and 
recurse  on  the  same  node. 

C.  If  these  L  pivots  are  2-balanced,  promote  only  the  2  balanced 
pivots  (instead  of  the  total  L)  to  the  parent,  partition  the  labels 
and  recurse  on  the  node  containing  the  searched  label. 


We  argue  that  this  procedure  is  worse  than  the  original  split  both 
in  the  (expected)  number  of  rounds  and  the  (expected)  total  band¬ 
width  (over  all  m  queries).  To  see  this  for  the  number  of  rounds, 
observe  that  the  alternate  procedure  chooses  its  partitions  in  the 
same  way  as  the  original,  but  always  drops  some  (or  all)  of  the 
pivot  points  resulting  in  larger  nodes  and  a  deeper  recursion  to 
reach  nodes  of  size  L.  For  the  case  of  bandwidth  most  of  the  cost 
comes  from  streaming  labels  to  the  client  to  partition  them  when 
splitting  a  leaf,  which  takes  0(k )  bandwidth  for  a  node  of  size  k. 
Now  consider  a  single  label  x  in  the  tree.  This  may  get  moved  be¬ 
tween  leaf  nodes  multiple  times  during  the  queries,  but  each  time  it 
is  moved  the  node  it  lands  in  is  larger  if  the  alternative  split  proce¬ 
dure  is  used  as  argued  above,  as  compared  to  the  actual  Split.  Thus, 
the  total  cost  of  all  splits  over  m  queries  is  larger  for  the  alternative 
split  as  it  will  require  repeatedly  streaming  these  larger  nodes  to  the 
client. 

For  the  remainder  of  this  proof,  we  analyze  the  alternative  pro¬ 
cedure  for  splitting  a  leaf  to  bound  the  costs  of  the  real  one. 

Round  complexity  for  a  single  search.  The  round  complexity  for 
a  search  can  be  computed  by  considering  the  round  complexity  for 
splitting  at  internal  nodes  (case  (i)  in  Section  3.4)  and  splitting  at  a 
leaf  (case  (ii)  in  Section  3.4). 

The  round  complexity  for  case  (i)  is  asymptotically  the  same  as 
the  height  of  the  tree.  Since  the  tree  is  re-balanced  such  that  each 
internal  node  contains  at  least  L/2  labels,  the  height  of  the  tree  is 
0(\ogL  n). 

As  for  case  (ii),  we  first  need  to  show  that  L  random  pivots  are 
2-balanced  with  constant  probability,  so  that  there  is  a  successful 
split  after  0(1)  many  unsuccessful  ones.  To  see  this,  define  an 
imaginary  sorted  list  (Xi, . . . ,  Xz)  that  contains  the  k  input  labels 
in  sorted  order,  equally  partitioned  so  each  X,  has  k/z  elements. 


Note  if  each  X,  contains  at  least  one  pivot  (out  of  the  chosen  L 
pivots),  then  the  pivots  must  be  2-balanced;  in  particular,  one  can 
find  such  pivots  by  choosing  one  from  each  X,.  By  the  Coupon 
Collector’s  Problem,  the  probability  that  L  pivots  hit  all  the  X,s  is 
constant. 

Now,  note  that,  by  the  definition  of  2-balanced,  after  each  suc¬ 
cessful  split  the  size  of  the  largest  partition  is  reduced  by  a  factor  of 
2/ 2  =  L/  log  L.  Thus,  the  total  number  of  successful  splits  needed 
and  also  the  total  (expected)  recursion  depth  is  0{ logL/logi  n ), 
which  simplifies  to  0{ logL  n)  when  n  >  16.  The  total  round 
complexity  of  the  POPE  protocol  is  therefore  0( logL  n). 

Total  bandwidth  over  m  search  queries. 

Height  of  the  tree.  First,  we  need  a  tighter  analysis  on  the  height 
of  the  POPE  tree.  For  this,  we  start  with  counting  the  total  number 
of  labels  in  the  internal  nodes.  The  total  number  of  Split  calls  over 
all  m  Search  operations  is  at  most  0(m  logL  n),  since  each  search 
has  0(\ogL  n)  recursion  depth. 

Now,  consider  the  sorted  labels  in  non-leaf  nodes  of  the  tree. 
Each  such  label  is  inserted  by  a  Split  operation  from  a  leaf,  and 
each  Split  inserts  at  most  2  labels.  Therefore,  the  total  number 
of  labels  stored  in  the  sorted,  non-leaf  portion  of  the  tree  T  is 
0(zmlogLn),  which  is  0(mL  log n).  Recall  the  sorted  labels 
in  the  non-leaf  nodes  of  the  tree  form  a  B-tree  with  between  L  and 
L/2  labels  per  node  (after  rebalancing).  Therefore,  the  maximum 
height  of  the  tree  is  height(T)  =  0(  logL  (m.L  log  n)j . 

Sending  sorted  labels  to  client.  Recall  that  the  round  complexity  of 
a  search  is  0{ logL  n).  Each  round  of  Search  involves  uploading  at 
most  L  labels  to  serve  as  partition  indices  to  the  client,  incurring  a 
total  bandwidth  of  Be  =  0(mL  logL  n). 

Sending  labels  in  non-leaf  buffers  to  client.  In  addition,  all  the  la¬ 
bels  in  buffers  along  the  search  path  are  sent  to  the  client  -  some 
more  than  once.  Observe  that  labels  in  buffers  only  move  to  a  lower 
buffer,  or  laterally  from  leaf  nodes  to  leaf  nodes  during  Split  op¬ 
erations,  which  means  that  any  label  in  non-leaf  nodes  must  be 
sent  to  the  client  at  most  height(T)  times.  Therefore,  the  ex¬ 
pected  total  bandwidth  for  the  labels  in  non-leaf  buffers,  across  all 
Search  operations,  is  Bin  =  0(n  •  height(T))  =  0{n\ogL  m  + 
W  log!,  (log  n)). 

Communication  cost  of  splits.  Observe  that  splitting  a  leaf  node 
of  size  k,  through  all  the  recursive  calls,  takes  bandwidth  O(k) 
since  0(k  +  k/z  +  k/z 2  +  . . .)  =  O(k).  So,  we  consider  the 
total  size  of  all  leaf  nodes  encountered  during  Search  operations 
to  compute  the  costs  front  splits.  The  worst-case  scenario  for  the 
construction  is  when  all  n  insertions  happen  before  all  m  searches, 
and  each  search's  splits  land  in  the  largest  remaining  leaf  node(s). 
Using  the  alternative  split  procedure,  the  largest  possible  leaf  nodes 
the  search’s  splits  will  land  in  (counting  only  successful  splits  as 
rounds)  have  the  following  sizes: 

-  (Round  1)1  node  of  size  n.  A  split  lands  on  this  node,  splitting  it  into 
nodes  of  size  at  most  n  ■  (2 /  z). 

-  (Round  2)  2  nodes  of  size  at  most  n  ■  (2 / z).  Note  the  total  size  of  the 
nodes  is  at  most  n. 

-  (Round  3)  z2  nodes  of  size  at  most  n  •  (2 /z)2.  The  total  size  is  at 
most  n,  etc. 

We  have  z'  —  m  wi£h  w  =  0(l°g L  m)>  and  m  largest 

leaf  nodes  are  encountered  by  round  w.  Since  the  total  size  of  the 
touched  nodes  in  each  round  is  at  most  n,  the  total  size  of  the  m 
largest  leaf  nodes  is  bounded  by  Bs  =  nw  =  0(n  logL  m). 

By  summing  up  Be,  Bin,  Bs,  we  find  that  the  total  bandwidth 
over  all  (n  +  m)  operations  is  at  most  0(rnL  logL  n  +  n  logL  m  + 
nlogL(logn)),  and  Theorem  1  follows. 


